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ABSTRACT 



An Internet Protocol telephone system and method uses a 
teleph qne-^26) to place and receive v oice o^er Interne t 
Protocol (yplEfcbased teleDDQne_calls and puj^c^witchgi 
tele phone network (gSTED=l^ & ^tete An off- 

hook condition with the telephone (26) is detected an d a 
s equence of signals generated jb.y I t 1 e {ejephojie^ Pffi ) is 
rexfiiy^d. At least a first signal generated by the telephone 
(26) is buffered while the system attempts to detect a 
predetermined signal that signifies a VblP-based call. Upon 
detection of the predetermined signal, the system intercepts 
subsequent signals in the sequence, absent the at least first 
signal that was buffered, and places the VoIP-based call via 
an internet (12). Otherwise, the system places the PSTN- 
based call via a PSTN (16). 

8 Claims, 5 Drawing Sheets 
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VOICE OVER INTERNET PROTOCOL net Protocol (\foIP)) via the customer's existing plain old 

TELEPHONE SYSTEM AND METHOD telephone service (POTS) telephone equipment operating in 

its current fashion. Such a configuration allows a user to 

FIELD OF THE INVENTION util ize_his existing POTS t^p h ones to place and rece ive 

-ru * • 1 * * i * . 5 "stand ard" public, switched telep hone network (PSTNV 

The present invention relates to a voice over Internet , — * — -r. * \ 7 fp / j « ~ t u~ ~~ .u. 

n . \ t , . . , ... based calls as well as VoIP-based calls, thus preventing the 

Protocol telephone system and method. c , , , . ' . . - 

F ^ user from purchasing redundant telephone hardware equip- 

BACKGROUND OF THE INVENTION mCDt - 

The preferred embodiment of the present invention sup- 
Most current systems for Internet Protocol (IP) telephony io plies customers with broadband internet access in their home 
or voice over an Internet Protocol (VoIP) are difficult and or ^i ncs& v i a a network premises gateway 10 as shown in 
sometimes impractical to use. Since these systems are piG. 1. T he whol e- home IP telephone s ystem with VoIP 
internet-based, they typically require the user to utilize his or functionality and assdaa^kAntemeU^ 
her personal computer (PC) to connect to an internet server ded m me networ k premises gateway 10, thus allowing the 
in order to place and receive internet-based calls. These PCs 15 n etwork premises.g atew.a v 10 to enable access to t he wide 
sometimes have a telephone connected to them, but often the are a netw ork (WAN) and th e internet 12 "" 
user is left using the PC's speakers and microphone for the ^SSSS^\oml^^T^^ the WAN and 
telephone conversation. Using the PC s speakers and micro- ^ {mmX u ^ aQOthcr ^ Qr service insidc mdr 
phone for such use is awkward and limits current user home 0f business flS shown m pjQ 2 In an alternative 
acceptability. 20 embodiment of the present invention, the network premises 
A solution to avoid using the PC to place and receive gateway 10 relies on the WAN and the internet 12 connec- 
internet-based calls is to provide t he user with a custom tivity from an external and independent internet access 
m ade telephone that suppor ts VoIP-based telep h6 1necfl ls.'A device 14 (i.e., an integrated services digital network (ISDN) 
prooiem witn this solution is that it requires the user to modem, a digital subscribe line (xDSL) modem, cable 
purchase additional telephone equipment to support the \foIP 25 modcm) c t c> ), 

capabilities. As such, the user is forced into purchasing In ^ pre f encd embodiment, the network premises gate- 
redundant telephone hardware equipment. wa y 10 connects to a PSTN 16_via.aJESTN network interface 
Thus, a need exists for a system and method that enables uj5llij^~l& \ The PSTN NIU 18 is t ypicaTl y found on the 
users to place and receive internet-based calls via the user's outside of most homes in the United States. This is the 
existing telephone equipment operating in its current fash- 30 demarcation point between the customer's equipment and 
ion. the telephone company's equipment. 

BRIEF DESCRIPTION OF THE DRAWINGS , M sbown , » FI(X 3 ' ,he network^emisesg^)^ 

also connects to an in -premises P OTS network 20 via a 

A preferred embodiment of the present invention is now 35 RJ-41 type interface 22. The RJ-41 type interface 22 allows 

described, by way of example only, with reference to the the network premises gateway 10 to arbitrate the in-premises 

accompanying drawings in which: POTS network 20 between "standard" PSTN-based calls 

FIG. 1 illustrates a whole-home Internet Protocol (IP) and VoIP-based calls to and from the WAN and the internet 

telephone system using a network premises gateway accord- 12. 

ing to the preferred embodiment of the present invention; 40 The primary interfaces or networks in the network pre- 

FIG. 2 illustrates the whole-home IP telephone system miscs gateway 10 are the in-premises POTS network 20, the 

using a secondary internet access device and service pro- PSTN 16 and tne broadband connection to the WAN and the 

vider to access the internet in an alternative embodiment of in \ ernet 12 FIG 3 illustrates an enlarged view of the 

the present invention' primary interfaces and their associated connections used to 

ni- 1 -11 . * » 1 . f nr 1 connect the network premises gateway 10 to the PSTN 16 

FIG. 3 illustrates the network premises gateway of FIG. 1 45 , . . n r A ™ * , -/ 

, . A . ** l. j * 1 l * 1 j and the in-premises POTS network 20. 

connected to a public switched telephone network and an r . 

in-premises plain old telephone service network according M sbown m FIG 3 > the connection from the m-premises 

to the preferred embodiment of the present invention; P0TS networtc f leads . 10 a " break oul " box ' a " fan out " box 

.... , , r L or a splitter 24 for the m-premises POTS network 20. Such 

FIG. 4 illustrates a hardware block diagram of the net- n w Jl„ trt t u„ nn-rc u~ _ ■ tU « 

. . * .- I - . 50 a connection allows all the POTS telephones 26 in the 

work premises gateway of FIG. 1 according to the preferred • t , *ui ■ *u . 1 * 

. * * • premises to be accessible via the network premises gateway 

embodiment of the present invention; ; A . . , . _ , . . 

y ' 10. It should be noted that the network premises gateway 10 

FIG. 5 illustrates a hardware block diagram of a telephony implemented in the present invention can be configured to 
subsystem, which is a component of the hardware block support multiple telephone lines for customers who cur- 
diagram of FIG. 4, according to the preferred embodiment of 55 rently havc more than onc analog te i C p aone ^ i n their 
the present invention; and DOme or business. 

FIG. 6 illustrates a hardware block diagram of an IP Further, it is important to note that the addition of a POTS 

telephony engine, which is a component of the hardware cordless telephone 28 operates with and supports the fea- 

block diagram of FIG. 4, according to the preferred embodi- tures of the present invention. An analog-based POTS cord- 

ment of the present invention. 60 i css telephone 28 has a wireless interface for connecting the 

cordless handset to an analog base or base station. The 
analog base or base station connects the POTS cordless 
telephone 28 to the in-premises POTS network 20 and to the 

The present invention implements a voice over Internet network premises gateway 10. An existing POTS cordless 

Protocol (IP) telephone system and method, suitable for 65 telephone 28 may be digital over the air (e.g., a 900 MHz 

whole-home and other uses, which enable^cus tamers, to telephone), but the associated base station has a standard 

place and receive internet-based calls (i.e., voice over Inter- analog interface. Thus, the present invention does not pre- 
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elude a POTS cordless telephone 28 from operating in its The POTS interface 40 contains the RJ-41 type interface 

normal fashion. 22 for connecting the network premises gateway 10 to the 

FIG. 4 illustrates a hi gh leve l hard warejblo^kdiagr amjaf in-premises POTS network 20 and the PSTN NIU 18. The 

th e network premis es g ateway 10. In the block diagram, POTS interface 40 comprises a stale detector for detecting 

there "is a connexion "to 'tEe^AN and the internet 12 and s an off-hook condition with the POTS telephone 26. The 

support for a wireless network of wireless digital handsets POTS interface 40 contains analog-to-digital converters 

30 or devices (additional advantages of supporting the (ADCs — which are not shown) for encoding the analog 

wireless network of wireless handsets 30 or devices are signals from the POTS telephones 26 to a digital sixty-four 

described in detail below). The components of interest in (64) kilobits per second pulse code modulation (PCM) for 

FIG. 4 are the system controller and memory component 32 10 the telephony crossbar 42 and from analog signals via the 

and the telephony subsystem 34 and the IP telephony H.323 PSTN 16 to the telephony crossbar 42. Likewise, the POTS 

engine 36, which are described in detail below. interface 40 contains digital-to-analog converters (DACs — 

The system controller and me mory component 3 2 con- which are not shown) for decoding the digital sixty- four (64) 

trols the functions and operation of the network premises kilobits per second (Kbps) PCM signals received from the 

gateway 10. User interaction with the network premises 15 telephony crossbar 42 for analog delivery to the POTS 

gateway 10 is controlled by a user interface program which telephones 26 and from the telephony crossbar 42 for analog 

resides in and is executed on the system controller and delivery to the PSTN 16. It should be noted that there is a 

memory component _3Z . The system controller and memory set of DAC and ADC for each connection, i.e., to the 

component 32 is designed to contain functions and operate in-premises POTS network 20 and to the PSTN 16 via the 

in a manner similar to a standard microprocessor controlled ^ PSTN NIU 18. 

computer system. The system controller and memory com- T he telephony crossbar 4 2 i s the "spine" o f t te ^j ephony 

ponent 32 is the heart of the network premises gateway 10 su bsystem^ : the telephony crossbar' 42 ' coupieslhe tele- 

and it controls all the network premises gateway's 10 phony manager 38 and the POTS interface 40 to each other, 

functions, operations, and states. The telephony crossbar 42 is also a router for all telephony 

The system controller and memory component 32 com- ^ c alls, PSTN and WP^ alike. The telephony crossbar 42 
prises a memory system (not shown), a comparator (not routes the digitally encoded, sixty-four (64) Kbps PCM, 
shown) and a microprocessor (not shown). The memory audio signals to and from the POTS interface 40, IP tele- 
system buffers at least a first signal generated by the POTS phony H.323 engine 36 and telephony manager 38 compo- 
telephone 26. T hejrojnpai a tpratte nents at the direction of the crossbar manager 56. 
m ined signal that signifies a V o|P-b ased_cal l. The rnicropro- 30 The crossbar manager 56 contains an application specific 
cessor ana associated' software program intercepts subse- integrated circuit (ASIC) for controlling the state and opera- 
quent signals in the sequence, absent the at least first signal tion of the telephony crossbar 42. It should be noted that the 
that was buffered, and places the VoIP-based call via an ASIC could be replaced with a bus controller which is made 
internet when l he predetermined signal is detected. up of an embedded microprocessor, memory and associated 

FIG. 5 graphically illustrates th e telephony subsystem 34 . 35 software residing on a single chip. The crossbar manager 56 

The telephony subsystem 34 comprises a teJle pliQrAyan ana^&fc maintains the data flow between the submodules of the 

38, a P OTS interfaced and a te lephony. crossbar 42. T he telephony subsystem 34 across the telephony crossbar 42. 

telephony subsystem 34 also comprises other components, The crossbar manager 56 further has the ability to mute 

suc h as an IP telephony int erface f*. a POTS output port 46 the signals and to inject music from a digital audio stream 

(used for connection of a local POTS telephone 26 to the 40 produced at the music on-hold synthesizer 50 for on-hold 

network premises gateway 10), a compression- calls. Since the crossbar manager 56 contains input for the 

decompression engine (CODEC) and packetizer 48 and a music on-hold module 50 for creating music, the user has the 

music on-bold module 50. Although the telephony sub- ability to place remote parties from the telephony call, either 

system 34 comprises a multitude of components, the fol- PSTN-based or VoIP-based, on hold, mute the signals and 

lowing description is limited to the telephony manager 38, 45 inject music from a digital audio stream produced at the 

the POTS interface 40 and the telephony crossbar 42. music on-hold module 50. At the control of the user via the 

The telephony manager 38 s uppjje^al Uhe^ fiincti Dns^fQr user interface, the system controller and memory component 
VoI P-basecl calls wmchjtreJn QjgMajl^ 32 enables the music on-hold module 50 and instructs the 
m eFSTOT i b lor POTS telephone s 26. For example, the crossbar manager 56 to replace the sixty-four (64) Kbps 
telephony manager ad comprises a dual tone^ r nultj- 50 PCM audio samples from the in-premises POTS network 20 
frequency (DX&IF\ de t ecti o n and n caJLpCQgress-,genecator r 52 . with sixty-four (64) Kbps PCM audio samples from the 
The DTMF detecUon and call progress generator 52 com- music on-hold module 50. Such a replacement causes inter- 
prises a^dele_ctpxfo r receivi ng , a seq ucncfwolsignals-gcnej- nal audio from the POTS telephones 26 to be muted (since 
a ted by^' the_POTS_ jeiel&p' ne^lni addition to performing these samples are no longer sent to the PSTN 16 or the 
DTMF detection, the DTMF detection and call progress 55 internet 12 (for VoIP-based calls)) and replaced with music, 
generator 52 generates DTMF signaling and supplies dial Thus, the telephony crossbar 42 links the on-hold call with 
tones and other appropriate call progress tones for the POTS the music on-hold module 50 of the telephony subsystem 34, 
telephones 26 when the network premises gateway 10 is and sends this music to the remote party instead of audio 
operating. The incoming call handler 54 generates ringing digitized from the in-premises POTS telephones 26 or other 
for the POTS telephones 26 when signaled by the system $o telephony devices in the premises. In the event that the user 
controller and memory component 32. prefers just muting the on-hold telephone call without 

Other features of the telephony manager 38 include: music, the system controller and memory component 32 

support for control of the telephony crossbar 42 via a instructs the crossbar manager 56 to "drop" or disregard the 

crossbar manager 56 (described in detail below); DTMF sixty-four (64) Kbps PCM samples from the in-premises 

generation and pulse dialing, flash hook, on/off-hook; and 65 POTS network 20. 

basic user interface for control of user interaction for VoIP The telephony crossbar 42 can also combine audio signals 

answering and origination. from various sources for call conferencing, including con- 
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ferencing PSTN -based calls with \b IP -based calls. The 
telephony crossbar 42 combines calls by sending multiple 
digital sixty-four (64) Kbps PCM streams to a common 
DAC in the POTS interface 40. Each DAC in the POTS 
interface 40 has associated circuitry (not shown) which sums 5 
the digital sixty-four (64) Kbps PCM streams into a single 
combined digital stream and automatically adjusts the single 
combined digital stream, via an automatic gain control 
(AGC) (also not shown), before the single combined digital 
stream enters the DAC. The AGC guarantees that the single 1Q 
combined digital stream remains within the dynamic range 
of the DAC. Sending multiple digital sixty-four (64) Kbps 
PCM streams to a common DAC causes audio from two 
telephone calls, VoIP based and PSTN-based, to be "added" 
together or combined, thus allowing call conferencing 
between multiple sources. 15 

T he I P t telepJ hoiiy^H323?^ ng ~ H.:323 
engird fo/ supp orting VoIPifeased calls. The IP telephony 
H.323 1 ' engine : jfr^te^ScsThe in-premises POTS tele- 
phones 26 to the broadband WAN and internet 12 connection 
which allows the POTS telephones 26 to place and receive 20 
VoIP-based calls. Likewise, the IP telephony H.323 engine 
36 may be used to support wired or wireless IP devices 30 
which support VoIP functionality (i.e., wireless IP devices 
which have a microphone, speaker and dialing pad) within 
the premises for PSTN-based and VoIP-based calls. 25 

The IP telephony H.323 engine 36 converts sixty-four 
(64) Kbps PCM sampled, POTS audio signals into H.323 
compliant audio streams for VoIP functionality. As graphi- 
cally shown in FIG. 6, a G.723.1 audio CODEC to PCM 58, 
60, telephony manager interface 62, networking interface 30 
64, H.225 multiplex & demultiplex subsections 66, 68 and 
H.245 signaling and control subsections 70, 72 are the 
components for the IP telephony H.323 engine 36. Two 
blocks are shown in the figure for the components and 
functions described above, i.e., H.225 multiplex & demul- 35 
tip lex subsections 66, 68 and H.245 signaling and control 
subsections 70, 72. T\vo of each of these components are 
shown and described to demonstrate the support of multiple 
VoIP calls in one network premises gateway 10. There is a 
software program executing on the system controller and 40 
memory 32 which performs the H.323 standard -based func- 
tions for VoIP-based call setup and teardown, including but 
not limited to standard Q.931 signaling for call setup and 
initiate. The software program executing on the system 
controller and memory 32 controls the telephony manager 45 
interface 62 for managing, at the H.245 subsections 70, 72, 
and audio and stream control to provide service over non- 
guaranteed links (e.g., transmission control protocol (TCP)/ 
IP). G.723.1 audio CODEC to PCM 62 performs the 
transcoding from sixty-four (64) Kbps PCM to 5.3 or 6.3 50 
Kbps low bit rate audio. 

I n ope ration, the DTMF detect ion angLc jdLprofifess-gen- 
e raiorI12j>£r^^ 

from a POTSlelepfiohT26f sendsTSgital representation of 
the information to the system controller and -memory com- 55 
ponent 32 for buffering into memory, and replaces the PSTN 
dial tone on all POTS telephones 26 with a slightly modified 
dial tone (i.e., the audible characteristics, tone and/or pitch 
of the PSTN dial tone is altered) when a POTS telephone 26 
is taken off-hook. The slightly modified dial tone reminds <so 
the user that he has the option of placing an internet-based 
call, thus indicating that the network premises gateway 10 is 
currently on-line. Should the network premises gateway 10 
be shut-off or down, the user hears the PSTN supplied dial 
lone when a POTS telephone 26 is taken off-hook. $5 

The telephony manager 38 also comprises an incoming 
call handler 54. The incoming call handler ^4 supports 



6 

PSTN call waiti ng noufemon Q ^r ^g_tnj^presjenceJ/oIP 
calls a nd ring Selection and generation witti cadence infor- 
mation to the user. For example, the incoming call handler 
54 signals the system controller and memory component 32 
and DTM Ejeje^Uon^gnii^nall .nr^cj^S-gcxter^tq^Sj jvhich 
no tifies the user of an incomin g ^TN - based | caUjwhen r _the 
present call is a -based call, system controller and 
memory" 32 is aierteo^'ia a standard H.323 alert message of 
an incoming VoIP call and signals the DTMF detection and 
call process generator 52 which notifies the user of ljyin^ 
incojrnjgJ^U^ a 
W^^d^call; and 2) an iacorn,in,F wfren 
the pre^m^paiys^gg^jj^as^c^ Notifying the user of 
an m coming JSTN-base^ ^lljH hp i n i rhf> ,p mcpnt raT1 
a PgTftf^asg d. call is currently supported by the local 
telephone company. 

In operation, during the presence of a call, the DTMF 
detection and call process generator 52 notifies fte.usfeL.of 
t he in c oming call py^ an audible„Johe__th at is user 
contigurab 'lerso that the user can' ascertain whether the cal l 
i s a PSTN-based ca ll or a VnlP-haseri call When no call is 
present, i.e., the POTS phones are on-hoo k, an incoming 
PSTN-based call and an incoming Vo IP-based call is_ p_ref- 
erably programmed to have different rmging^dence, thus 
informing the user whether the incoming call is a PSTN- 
based or VoIP-based call based solely on the ringing* 
cadence. 

The system control and memory component 32 in form s, 
the user of an incoming, PSTN-based or V oJP-based^ca ll by 
transmitting th e_following: _caller_identification inform ation 
( discussed in detail below ); an electronic mail (email) mes- 
sage to a known user configuration addresses); or a tele- 
phony page from the PSTN 16 to a standard pager. 

The system controller and memory component 32 is 
configurable, based on information from the incoming call 
handler 54 or receipt of H.323 alerts, to notify the user of an 
incoming electronic mail message, an incoming VoIP-based 
facsimile and an incoming PSTN-based facsimile in the 
same manner described above with respect to incoming 
PSTN-based and VoIP-based calls. For example, email mes- 
sage alerts are sent by having the remove email mailbox ping 
the network premises gateway 10, the system controller and 
memory component 32 would activate a program in the 
system and notify the incoming caller handler 54 on receipt 
of the ping from the email messaging system. The program 
or set of operations at the system controller and memory 
component 32 would instruct the call handler 54 to ring, 
with a special cadence, the POTS telephone 26 notifying the 
user of an email message arriving at the user's remote email 
mailbox. Internet mailboxes typically conform to known 
standards, e.g., simple mail transfer protocol (SMTP), post 
office protocol (POP), internet message access protocol 
(IMAP), etc. Most of these standards support notification 
based on receipt of email messages. In the event that a user 
has a non-standard mailbox, other systems can be designed 
that periodically check the mailbox and then send notifica- 
tion to the incoming call handler 54 based on the detection 
of new email messages in the mailbox. This assumes that a 
program resides on the system controller and memory 
component 32 for periodically checking whether new mail 
has arrived. This program is similar to the systems which are 
readily available to customers today, such as, biff and rbiff 
(UNIX daemons), PCBIFF (biff for Windows PCs), macbiff 
(biff for Macintosh systems) and the Windows PC program 
check mail. 

Alternatively, the user configures the system so that the 
system controller and memory component 32 instructs the 
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DTMF detection and call process generator 52 to use the system contained in the system controller and memory 

PSTN 16 to send a "standard" telephony-based page on component 32 or as dedicated hardware, i.e., an ASIC) is 

receipt of an email message. Once the system controller and integrated into the incoming call handler 54 to provide the 

memory component 32 detects the presence of new mail in following further options to notify the user of an incoming 

the users mailbox a local program can instruct the DTMF $ facsimile: translating via optical character recognition into a 

detection and call progress generator 52 to initiate a new call tcxt mcssagc ^ further into a voice message for retrieval 

to the PSTN 16. This call is to a user configured telephone ^ifo lhe premises or via a dial up from a remote location; 

number of a pager and then the system controller and or translaUng optical charac ter recognition into a tcxt mes- 

memory component 32 sends pertinent, user configured, and farther - m{Q an emajl m 

information to me pager. The information sent to the pager ^ . . „ , „ tJ 

i j u • • . i- j • *u j r *u i 10 The incoming call handler 54 also supports caller ldenu- 

may include, but is not limited to, the sender of the email _ . . , 6 _ . . rr . , _ „ 

*L a ,k-™w*~„w*;.i D «r n „j /n ,,L n ri cation in the same format that is known m the art. Caller 

message, the subject/title of the message, and/or the message ., 4 . . c . . . . , 

. , identification information is passed as a 1200 baud, seven 

_,%.*. - - - - (7) data bits, one (1) stop bit encoded data stream for sending 

With respect to email messages, the system controller and ,,. *u nc-™ . i c 

^ .i / .i jj- • i calling party information across the PSTN network for 

memory component 32 provides the following additional 1C • * _i j- i * n -j *-c **ui 

3 \, At r . \ is receipt and display at caller identification compatible 

options to notify the user of an incoming email message: , . A i r * j ♦ ♦ c n j 

r , . , J - , & ? devices. An example of a formatted output for caller iden- 

translating the content of the email message into a voice tfljle devjce as ^ owa m the ai1 ^ the 

message for retneval inside the premises (i.e., at any of the following* 

POTS telephones 26) or via dial up from a remote location s „ 

(i.e., from any PSTN connection); or converting the content ^ ate 

of the email message into a facsimile. Similar to the inter- Tunc 1:34 PM 

face discussed with paging or ringing, the system controller Number — (407) 555-1111 

and memory component 32 contains a program which Since the network premises gateway 10 implemented in the 
integrates a text-to-speech processor (not shown but con- present invention interfaces between the in-premises POTS 
tained as software in the system controller and memory ^ network 20 and the WAN and internet 12, the network 
component 32 in a manner which computers generate speech premises gateway 10 receives \bIP-based calls and trans- 
today) to enable reading of the email message over the laics IP address information into a format that is compatible 
POTS telephones 26. For example, notification of the email with the caller identification format above. Most of the VoIP, 
message pings the system controller and memory compo- H.323-based calls contain more detail in their call state 
nent 32 and the system controller and memory component 30 information (as will be described later), however, there are 
32 instructs the incoming call handler 54 to ring the POTS cascs and times when the user wants to have a calling party's 
telephone 26 (with a special cadence). If the user picks up machine name looked up from the standard domain name 
the POTS telephone 26, the system controller and memory services (DNS) available on the internet 12. In such a 
component 32 reads the email message to the user over the situation, look-ups for domain naming system is supported 
POTS telephone 26. It should be noted that a speech-to-text 35 bv containing a software system on the system controller 
processor (not shown) could be integrated to perform the an d memory component 32 similar to nslookup, a standard 
opposite function, speech-to-email message, from any UNIX command. For example, nslookup on "207.25. 7 1.29" 
POTS telephone 26 in the premises. yields: 

For example, the whole-home IP telephone system has % nslookup 207.25.71.29 

memory, answers the incoming telephone calls, and stores 40 Name Server: argus.cso.uiuc.edu 

messages from the calling party in the system memory, Address: 128.174.5.58 

either PSTN-based or VoIP-based, in the event that no one Name: www9.cnn.com 

is able to pick up the POTS telephone 26 or answer call with Address: 207.25.71.29 

a digital handset 30 in the premises. In other words, the i n this example, the system controller and memory compo- 
whole-home IP telephone system is integrated in a manner 45 nent 32 accesses the internet 12 and supplies the name 
so that it operates as an answering machine for both PSTN- "www9.cnn.com". The user is able to ascertain that the 
based and VoIP-based calls alike. Once a remote caller calling party is located at one of the CNN hyper text transfer 
leaves a message on the system, the system controller and protocol (http) servers. Since the called party in the VoIP 
memory component 32 may be configured to access the scenario may only receive the IP address of the calling party, 
WAN and internet 12 and send email messages based on the 50 nslookup generates the name and the "standard" caller 
voice message that the calling party left. The email message identification format is used to transmit the data to the 
is stored in the system memory of the system controller and in-premises caller identification device. The system control- 
memory component 32. Using speak-to-text capabilities i er anc j memory component 32 instructs the system to 
which are readily available today, the message is encoded convert the data gathered from the DNS lookup to analog 
into text and included with the aforementioned email mes- 55 instructions compatible with standard caller identification 
sa 8 e - functions. The system controller and memory component 32 

Likewise, the network premises gateway 10 can be con- instructs the DTMF detection and call progress generator 52 

figured by the user to send a page notification based on a to translate the information to the analog modem codes, used 

message that is left on an answering machine by the calling for caller identification, and then the system controller and 

party. It is important to note that the voice mailbox is the 60 memory component 32 instructs the incoming call handler 

same for both VoIP-based messages and "standard" voice 54 to send the information on the POTS network 20 to 

messages from the PSTN. Sending a page notification based compatible caller identification devices, 

on a message that is left on an answering machine by the Further, more information is supplied by the IP telephony 

calling party operates just as paging on receipt of an email H.323 engine 36, which is received from the incoming 

message. 65 H.323 VoIP-based call. This information is provided during 

With respect to facsimiles, either PSTN-based or VoIP- the H. 225.0 and Q.931 signaling and messaging functions as 

based, an optical character recognizer (either as a software called for in the H.323 standard. For example, the IP 
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telephony H323 engine 36 has the ability to send additional 
subscriber (calling party) information (e.g., name, location, 
personal information, such as "finger" information). This 
information is translated and sent on the POTS network 20 
and to compatible caller identification devices in the manner 
discussed above. 

For the case where the calling party only allows the IP 
telephony H.323 engine 36 to distribute/broadcast the 
address of the originating call, the network premises gate- 
way 10 performs a nslookup, or equivalent, and references 
the name and IP address against a database contained in the 
system controller and memory component 32 of the network 
premises gateway 10 in order to do a name look-up. 

After the translation, the caller identification information 
is sent over the in-premises POTS network 20, at the time of 
ringing the POTS telephones 26 for an incoming VoIP call, 
in the standard and known analog caller identification format 
which is supported by caller identification systems available 
on the market today. This makes existing caller identification 
boxes and POTS telephones 26, which have integrated caller 
identification functions, compatible with the VoIP system. 

In operation, when placing a call, the network premises 
gateway 10 via the DTMF detection and call progress 
generator 52 detects an off-hook condition with a POTS 
telephone 26. The DTMF detection and call progress gen- 
erator 52 receives a sequence of signals generated by the 
POTS telephone 26 and buffers at least the first signal 
generated by the telephone. This technique is identical to 
that described in Newlin et al., U.S. patent application Ser. 
No. 08/735,295 filed Oct. 22, 1996, entitled Apparatus, 
Method and System for Multimedia Control and 
Communication, Motorola Docket Number PD05688AM. 
The DTMF detection and call progress generator 52 
attempts to detect a sequence of predetermined signals call 
(e.g., the signals generated from the "#" keys of the POTS 
telephone 26) that signify a "non-standard" PSTN-based 
call, in this case a VoIP-based call. It should be noted that, 
alternatively, a single predetermined signal can signify a 
"non-standard" PSTN-based call as well. 

When the sequence of predetermined signals is detected, 
the network premises gateway 10 enters a VoIP mode, 
intercepts subsequent signals in the sequence, absent the 
signals buffered, and places the VoIP-based call via the 
internet. Once in the VoIP mode, the network premises 
gateway 10 supports some form of dialing capability so that 
the user can dial an IP number directly. For example, the user 
could dial "192#98#18#83" which would signify the IP 
number "192.93.18.83". The system controller and memory 
component 32 interacts with the DTMF detection and call 
progress generator 52 to detect the numbers dialed and 
control H.323 engine for placing the internet-based call. The 
network premises gateway 10 may also support voice 
(computer- generated) menuing in order to make selecting of 
called users easier. All functions of the user interface would 
be controlled by the system controller and memory compo- 
nent 32. 

When the sequence of predetermined signals is not 
detected, the network premises gateway 10 enters a POTS 
mode and transmits the sequence of signals, including the 
signals buffered, to the PSTN 16. The user interacts with the 
POTS telephone 26 and the PSTN 16 as normal. 

As mentioned briefly previously, the addition of a wireless 
digital device or handset 30 (e.g., a personal digital assistant 
or any other digital device including a simple dedicated 
digital telephony handset) which supports telephony fea- 
tures via its own user interface and connects via a wireless 
link to the network premises gateway 10 provides the same 
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features as above along with additional features to the 
present invention. Fundamentally, the present invention pro- 
vides system integration to use a wireless digital handset for 
PSTN-based and VoIP-based calls via a common interface 
without having a separate CODEC exclusively for the 
\bIP-bascd calls. 

The handset 30 is digital and the digital data is converted, 
at the network premises gateway 10, from sixty-four (64) 
Kbps PCM to low bit rate data for VoIP functionality without 
going to the analog domain. For example, when placing an 
outgoing call from the digital wireless handset 30, the digital 
wireless handset 30 receives a type-of-call selection and a 
sequence of signals representative of a telephone number to 
place the outgoing call following the type-of-call selection 
from a user. Analog signals (e.g., an electrical signal from a 
microphone generated by the speaker's voice) are converted 
to digital signals at the digital wireless handset 30 and 
transmitted to a network premises gateway 10. The digital 
signals are translated to a format compatible for a network 
used in completing the outgoing call at the network premises 
gateway 10, wherein the network is the PSTN 16 for 
PSTN-based calls and an internet 12 for VoIP-based calls. 
When receiving an incoming call at the digital wireless 
handset 30, digital signals are transmitted from the network 
premises gateway 10 to the digital wireless handset 30 and 
converted to analog signals at the digital wireless handset 30 
in order to be broadcasted to the user via the digital wireless 
handset's speakers). Cost and complexity reduction is 
inherent to this design. The H.323 coding, i.e., call setup and 
management, is still performed at the network premises 
gateway 10 and does not need to be reproduced in the 
handset; however, the CODEC at the wireless digital hand- 
set 30 is used to convert between the analog and digital 
domains. 

Integrating the wireless digital handset 30 which operates 
as a telephony cordless telephone with the WAN and internet 
12 connection allows a user to access the configuration of 
the network premises gateway 10, and thus the characteris- 
tics of their WAN and internet connection 12, from their 
wireless digital handsel 30. Moreover, as stated above, the 
user can access email messages from the wireless digital 
handset 30 without, however, going off-hook on the 
in-premises POTS network 20. 

Caller identification could be provided at the wireless 
digital handset 30 for VoIP calls as described above as well. 
With a wireless digital handset 30, however, caller identi- 
fication information would not have to be converted into 
analog telephone signals, in other words, a proprietary 
digital caller identification could be utilized for the digital 
handsets. The caller identification information is sent 
directly to the wireless digital handset 30 via the IP protocol. 

The whole -home IP telephone system is configured in a 
manner so that if the network premises gateway 10 is shut 
off or in a crashed state, the in-premises POTS network 20 
operates exactly as if the network premises gateway 10 was 
not installed. Such a configuration allows the RJ-41 inter- 
face 22 and the interface to pass PSTN-based calls on the 
PSTN connection 16 to ensure that PSTN-based calls are 
placed and received even when the network premises gate- 
way 10 is disconnected. Thus, the present invention main- 
tains the reliability and availability of the PSTN 16. 

While the invention has been described in conjunction 
with a specific embodiment thereof, additional advantages 
and modifications will readily occur to those skilled in the 
art Moreover, even though the present invention has been 
designed to support the H.323 standard for VoIP 
functionality, the network premises gateway 10 can also be 
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designed to support other, possibly proprietary, VoIP func- 
tionality techniques. The invention, in its broader aspects, is 
therefore not limited to the specific details, representative 
apparatus and illustrative examples shown and described. 
Various alterations, modifications and variations will be 
apparent to those skilled in the art in light of the foregoing 
description. Thus, it should be understood that the invention 
is not limited by the foregoing description, but embraces all 
such alterations, modifications and variations in accordance 
with the spirit and scope of the appended claims. 
We claim: 

1. In an Internet Protocol telephone system using a 
telephone to place and receive voice over Internet Protocol 
(VoIP)-based and public switched telephone network 
(PSTN)-based telephone calls, a method comprising: 

detecting a presence of an incoming telephone call; 

detecting an off-hook condition from the telephone; 

receiving a sequence of signals generated by the tele- 
phone; 

buffering at least a first signal generated by the telephone; 

attempting to detect a predetermined signal that signifies 
a VoIP-based call; 

intercepting subsequent signals in the sequence, absent 
the at least first signal that was buffered, and facilitating 
the VoIP-based call via an internet when the predeter- 
mined signal is detected; and 

signaling, via and audible tone, a user of the telephone 
during the VoIP-based call of the presence of a tele- 
phone call, the audible tone having a first ringing 
cadence when the telephone call is a VoIP-based call 
and the audible tone having a second ringling cadence 
when the telephone call is a PSTN-based call. 
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2. The method according to claim 1 wherein the incoming 
telephone call is a VoIP-based call. 

3. The method according to claim 1 wherein the incoming 
telephone call is a PSTN-based call. 

s 4. The method according to claim 1 further comprising 
ringing the telephone via the internet when an electronic 
mail message arrives at a mailbox. 

5. The method according to claim 1 further comprising, 
when the predetermined signal is not detected that signifies 
10 a VoIP-based call: 

determining that a telephone call is being made; 
transmitting the sequence of signals generated by the 
telephone to a PSTN; 
15 detecting a presence of an incoming VoIP-based call 
having Internet Protocol address information; and 
signaling a user of the telephone during the telephone call 
of the presence of the incoming \bIP-based call. 
^ 6. The method according to claim 5 further comprising: 
translating the Internet Protocol address information into 
a formal compatible for caller identification to create 
VoIP caller identification information; and 
presenting to the user of the telephone the VoIP caller 
25 identification information. 

7. The method according to claim 6 wherein the step of 
presenting to the user of the telephone occurs at the time of 
signaling the user of the telephone during the telephone call 
of the presence of the incoming VoIP-based call. 
30 8. The method according to claim 1 wherein the telephone 
is cordless. 

* * * * * 
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(57) ABSTRACT 

When a s ubscriber calls into its Internet Service Provid er 
flSPL a central o&ce receiving the call is triggered" to 
perform a Local Number Portability (LNP) query. This LNP 
query is sent to an Intelligent Traffic Routing and Control 
(INTRAC) unit resident on a Service Control Point (SCP) 
which determines whether the call is to an ISP. If the call is 
to an ISP, the INTRAC unit polls a Remote Authentication 
Dial-In User Service (RADIUS) server to determine whether 
resources are available. The RADIUS server tracks the 
resources of the ISP and of other ISPs and informs the SCP 
of the available resources. The SCP then inserts the Local 
Routing Number (LRN) of the preferred resource into a 
reply that is sent to the central office. If resources are not 
available, the call is terminated before signaling occurs with 
any switch associated with the ISP. On the other hand, when 
resources are available, the subscriber can be directed to the 
preferred resource for the subscriber. The subscriber, for 
instance, can be directed to an access server within the ISP 
that has excess capacity or can be directed to an access 
server that provides the best service for the subscriber, 
whereby subscribers can be directed to X2 type service if 
they have an X2 modem or to K56Flex type service if they 
have a K56Flex modem. As another example, if one ISP is 
at maximum capacity, the subscriber can be directed to a 
second back-up ISP. 
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NETWORKS, SYSTEMS AND METHODS 
FOR INTELLIGENTLY ROUTING TRAFFIC 
WITHIN A TELEPHONE NETWORK 

FIELD OF THE INVENTION 5 

The present invention relates generally to networks, sys- 
tems and methods for routing traffic within a telephone 
network and, more particularly, to networks, systems and 
methods for intelligently directing data traffic away from the 
Public Switched Telephone Network. 10 

BACKGROUND OF THE INVENTION 

The Public Switched Telephone Network (PSTN) is the 
backbone for providing telephony services to business and 15 
individuals in the United States. The PSTN includes a 
number of switches, generally designated as Service Switch- 
ing Points (SSPs), for interconnecting a calling party's line 
to a called party's line. Prior to the 1960*s, to complete a call 
between a calling party and a called party, signaling would ^ 
occur over the trunk circuits between the switches to ensure 
that the called party was not busy and to establish a 
connection between the two parties. This earlier version of 
the PSTN was rather inflexible in that changes to the PSTN 
could only occur with the replacement of the hardware in the ^ 
PSTN. For instance, at this time, the SSPs were hard-wired 
and had to be replaced with a new SSP in order to update the 
switch's capability. The switches, however, could not be 
quickly updated since the standards and specifications had to 
be well-defined for the various switch vendors. To address 30 
the delays in updating switches, these hard-wired SSPs were 
ultimately replaced with SSPs that had stored program 
control (SPC). As a result, rather than replacing an entire 
SSP, the SSP could be modified to enable a new feature 
simply by updating the software in the SSP. Even with SPC 35 
in the SSPs, the PSTN was still limited in the services that 
it could provide. 

A major advancement to the PSTN occurred in the 
mid-1970's with the introduction of Signaling Transfer 
Points (STPs) and Signaling System number 7 (SS7) pro- 40 
tocol. With the addition of SS7 and STPs to the PSTN, call 
setup information is routed over a signaling network formed 
between the STPs and no longer occurred directly over the 
trunks. For instance, a calling party's SSP would send a data 
query from one of its associated STPs to an STP associated 45 
with the called party. The called party's STP would then 
determine whether the called party's line was idle and would 
perform the necessary signaling over the SS7 data network 
to connect the call. Thus, whereas before call setup signaling 
would occur over the voice trunks, the STPs and SS7 50 
signaling bypass this traffic away from the voice trunks and 
onto dedicated data lines. As a result, the capacity of the 
PSTN to carry voice calls was greatly increased. 

In the mid-1980's, demand for additional services from 
the PSTN resulted in the Intelligent Network (IN)- Irj 55 
general, IN provides service logic external to the SSPs and 
places this logic in databases called Service Control Points 
(SCPs). To accommodate IN, the SSPs have software to 
delect service-specific features associated with IN. The 
software in the SSPs define hooks or "triggers" for the 60 
services that require use of an SCP. In response to a trigger, 
an SSP queries an associated SCP for relevant routing 
information. For instance, IN permits 800 service and call- 
ing card verification service, both of which require a query 
from the SSPs to the SCP through an STP and the return of 65 
routing information to the SSP through an STP. A Service 
Management System (SMS) was also introduced into the 
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PSTN with IN and provides necessary support in service 
creation, testing, and provisioning. The SMS communicates 
with the SCPs and provides software updates to the SCPs. 

The demand for increased capabilities has more recently 
transformed the IN into an Advanced Intelligent Network 
(AIN). The AIN differs from the IN in that the A1N provides 
service independent capabilities whereas the IN was limited 
to service -specific capabilities. AIN provides a high level of 
customization and builds upon basic services of play 
announcement, digit collection, call routing, and number 
translation. Some examples of AIN services include abbre- 
viated dialing beyond a central office, do not disturb service 
for blocking calls from certain numbers or at certain times, 
and area number calling service which allows a company to 
have one advertised telephone number but to have calls 
routed to a nearest business location. 

The ability to provide Local Number Portability (LNP) is 
perhaps the latest enhancement to the PSTN. The local 
exchange carriers (LECs) are now required under the Tele- 
communications Act to provide local number portability so 
that subscribers can move or "port" their number from one 
service-provider to another service-provider. Traditionally, 
the function of a telephone number within the PSTN was 
both to identify the customer and to provide the PSTN with 
sufficient information to route a call to that customer. To 
allow a customer to change its service-provider while at the 
same time keeping the same telephone number, the tele- 
phone number can no longer by itself provide the means to 
inform the network of the customer's location. A database, 
called a LNP database, stores routing information for cus- 
tomers who have moved or ported to another local-service 
provider. The LNP database contains the directory numbers 
of all ported subscribers and the location routing number of 
the switch that serves them. With LNP, the SSPs will query 
an LNP database through a STP in order to correctly route 
calls to a ported telephone number. 

The evolution of the PSTN from providing POTS to AIN 
services has primarily been driven by the need to support 
voice telephony. The PSTN, however, is not limited to voice 
telephony but is increasingly being relied upon for data 
services. Modems are the predominant means data is trans- 
mitted over the PSTN. The integration of voice services with 
data services is not a new phenomenon and the PSTN has 
traditionally accommodated these combined services 
through its Integrated Services Digital Network (ISDN) 
lines. An ISDN line can carry both voice and data traffic or 
can be optimized for data-only service at a speed of 128 
kbps. Although the ISDN has been available for close to 20 
years, the use of the ISDN line is not pervasive and estimates 
place the number of Internet subscribers employing ISDN 
service at only 1,4 percent. 

Despite the infrequent use of ISDN service, the need for 
data services is quite extensive. The PSTN has been 
designed to carry a large amount of voice traffic with each 
voice call lasting, on average, just a few minutes. While an 
average voice call is approximately 3.5 minutes, the average 
Internet call lasts over 26 minutes. Considering that Internet 
traffic on the PSTN is soon expected to exceed the combined 
traffic of both voice and facsimile, the capacity of the PSTN 
will soon be stretched to its limits. The LECs have been 
meeting this higher demand for capacity by deploying 
additional switches and other elements within the PSTN. 
Unfortunately for the LECs, the cost of this additional PSTN 
equipment is being born almost entirely by the LECs since 
they will see little increase in their customer base. This 
added expense to each LEC is approximately Si 00 million 
per year and is thus a considerable expense to the LECs. 



03/22/2004, EAST Version: 1.4.1 



US 6,415,027 Bl 

3 4 

An immediate need therefore exists to alleviate strains on external to the INTRAC unit. As an example, the resource 

the PSTN due to Internet traffic. Some solutions to handle tracker defines a counter for each access server within an ISP 

Internet congestion have been proposed in the Bellcore and sets the maximum value of the counter to the available 

White Paper entitled Architectural Solutions To Internet resources of that access server, such as the number of 

Congestion Based on SS7 and Intelligent Network s modems. The resource tracker monitors the start and stop 

Capabilities, by Dr. Amir Atai and Dr. James Gordon. Many messages routed to a Remote Authentication Dial-In User 

of these solutions discussed in this paper, however, require Service (RADIUS) server and accordingly adjusts the value 

the design, development, and deployment of new network of the counter to reflect the available resources. The resource 

elements within the PSTN. For instance, several of the tracker adjusts values in the resource table to reflect the 

solutions introduce an Internet Call Routing (ICR) node 10 current capacities of the ISPs, The INTRAC unit can there - 

which can perform SS7 call setup signaling and which is fore query the resource table in real-time to discover the 

used to direct Internet calls to a data network. Other solu- available resources and, if resources are not available, the 

tions rely upon a Remote Data Terminal (RDT) to alleviate call can be quickly re-routed or terminated, 

congestion while other architectures propose the use of both [ n addition to allowing data calls to be intercepted when 

ICRs and RDTs. The architectures described in the Bellcore is resources are not available, data calls can also be more 

White Paper are generally long-term solutions which offer efficiently managed. A subscriber's call, for instance, can be 

limited assistance to the LECs in the near future. A need directed to preferred Point Of Presence (POP) of an ISP or 

therefore still exists for systems and methods for addressing (o a preferred access server within an ISP. The routing of the 

the ever-increasing amount of data traffic in the PSTN. customer's call can be made based on geographic locations 

SUMMARY OF THE INVENTION 20 or based on a preferred service for the subscriber, such as 

™ A . . . . . , . , ., , modem (X2 or K56Flex) or ISDN service. The subscriber's 

The present invention addresses the problems described cM ^ be ^ a pp ropria t e ISP. For 

above by providmg networks systems and methods for ^ when ^ subscriber>s |sp u ^ c it lhe 

directing Internet calls and other data ^aUsaway from the ^ be dirccted , sp ^ ^ ^ 

Public Switched Telephone Network (PSTN). A call to an M servioe J t0 a preferred ISP . 

Internet Service Provider (ISP) triggers a query to a Service „ „ ... 

Control Point (SCP). When the query is received at the SCP, , One manner of controlling the destination of dau calls .s 

the SCP determines whether the called telephone number is to™* the usc of Uca ' Routing Numbers (LRNs^When 

a data call. If it is, the SCP routes an inquiry to an Intelligent f 15 ^ ? n SSP 10 ,he LNP SCP ' ,he 

Traffic touting and Control Unit (INTRAC) which, accord- 30 ™ AC . ass i 0Clat6d Wlth «■» LNP SCP provides the 

ing to one aspect of the invention, acquires routing direc- «»>med in .the. response to the SSP. This LRN may be 

tions and provides them to the SSP. The routing directions obtamed b ,y the INTRAC unit from the resource table or by 

are obtained through use of a resource table. a L n ^ource tracker. The external resource tracker or 

T .. e j ... ... oor , ... . . the INTRAC unit derives a preferred LRN based on the 

In the preferred embodiment, the SSP is triggered to „ , . ., . . £ , iL ... „ 

r t i vt i_ n . l V*. /i Km\ . o^n called party, and possibly also based on the calling party. For 

perform a Local Number Portability (LNP) query to an SCP 35 • . .c • r ■ #u ? . 

f, t - t vm 11 • n. ri/*in «i * instance, the information in the resource table can be used to 

that performs LNP call processing. The SCP determines , . ., , . r , ... 

, J ... * . I. , b . f — -r — 7—t r, direct a subscriber s call to a preferred access server within 

whether the call is a data call and, if it is, directs the call lc , n r . , . 

■ r ; ;,„ u . V IK _, A ~ an ISP or even to an access server in a backup ISP. 

away from an LNP call processing unit to the INTRAC unit. r 

Both the LNP call processing unit and the INTRAC unit are Accordingly, it is an object of the present invention to 

Service Package Applications (SPAs) that are resident on the 40 ? rcmde nelworks > svslems > and met h ods for educing traffic 

SCP. The SCP has a database of data-related telephone m ^ PS™- 

numbers and uses a Routing Key to direct the query to the 11 k another object of the present invention to provide 

INTRAC unit. For queries related only to LNP, the calls are networks, systems, and methods for efficiently routing data 

processed in the conventional manner and are not effected by calls. 

the INTRAC unit. 45 It is a further object of the present invention to provide 

Instead of, or in addition to, receiving routing directions, networks systems, and methods for routing calls to a pre- 

the INTRAC unit may also determine whether resources are ferred resource within the ISP. 

available for connecting a subscriber's call to its destination. It is yet another object of the present invention to provide 

According to this aspect of the invention, the INTRAC unit networks, systems, and methods for redirecting calls to a 

includes a resource table that may be updated by an externa] 50 secondary resource when a first ISP is at peak capacity, 

or internal resource tracker. After receiving an LNP query, Other objects, features, and advantages of the present 

the INTRAC unit determines from the resource table invention will become apparent with respect to the remain- 

whether the called party has capacity to process the sub- der of this document. 

scriber's call. If resources are available, the INTRAC returns BRIEF DESCRIPTION OF THE DRAWINGS 

the routing directions for the preferred provider of the 55 

service within the Local Routing Number (LRN) of the LNP The accompanying drawings, which are incorporated in 

response. If service is not available, then the call to the ISP and form a part of the specification, illustrate preferred 

is either redirected to another LRN or is intercepted, in embodiments of the present invention and, together with the 

which case the subscriber receives a busy signal or other description, disclose the principles of the invention. In the 

error treatment. As a result, when resources are not 60 drawings: 

available, the signaling between the subscriber and the ISP FIG. 1 is a diagram of a conventional network for 

provider is eliminated, thereby reducing traffic within the providing data service to a subscriber; 

PSTN. On the other hand, when resources are available, the FIG. 2 is a more detailed diagram of an Internet Service 

subscriber can be directed to those resources in an efficient Provider and RADIUS server for the network shown in FIG. 

manner. 65 1; 

The resource tracker monitors the resources consumed by FIG. 3 is a diagram of a network according to a preferred 

an ISP or group of ISPs and may be either internal or embodiment of the invention; 
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FIG. 4 is a flow chart depicting a process of handling a 
subscriber's data call; 

FIG. 5 is a flow chart depicting a process of generating an 
ISP resource inquiry; 

FIG. 6 is a flow chart depicting a method of monitoring 5 
consumption of resources; 

FIG. 7 is a diagram of a Common Channel Signaling 
System 7 (CCS7) message format; 

FIG. 8 is a more detailed diagram of an Service Control J(J 
Point according to a preferred embodiment of the invention; 

FIG. 9 is a flow chart of a method of processing queries 
at the SCP of FIG. 8; and 

FIG. 10 is an example of a resource table according to a 
preferred embodiment of the invention. 15 

DETAILED DESCRIPTION 

Reference will now be made in detail to preferred 
embodiments of the invention, non-limiting examples of 
which are illustrated in the accompanying drawings. 20 
I. Conventional Network 

With reference to FIG. 1, the Public Sw jjtcfiefj^fcfcphnne 
Networl^PSTN) 10 provides local and long distance tele- 
phony service to its subscribers, such as those represented by 
telephones 12, facsimile machines 13, and computers 14. As 25 
discussed above, the PSTN 10 includes Service Switching 
Points (SSPs), Signaling Transfer Points (STPs), Service 
Control Points (SCPs), and Service Circuit Nodes (SCNs), 
which are collectively represented by the PSTN 10. The 
PSTN 10 also provides a connection to th e I ntetne.l3flL such 30 
as through an Internet S ervice fro,gidei_fl§p_ j20 . A sub- 
sc riber usmg^ajcojflputer 14 must direct a j c all throug h the 
PST^JLO in order to "gain access to his or hffisPjOV which 
in turn provides access to the data network' called the 
Internet 30, This arrangement of going through the PSTN 10 35 
presents a number of problems and challenges, some of 
which have already been described. 

The PSTN 10, as shown in more detail in FIG. 2, includes 
a number of central offices (COs) 16 and tandem switches 
(T) 18. Typically, a plurality of subscribers are connected to 40 
a single central office 16 and the central offices 16 are 
inter-connected to each other through one or more tandem 
switches, such as the tandem switch 18. The ISP 20 has an 
Access Server (AS) 22 connected to the PSTN 10 through a 
number lines, which are often primary rate ISDN (PRI) lines 45 
24. The PRI lines 24 extend between the ISP 20 and a single 
central office 16 within the PSTN 10 and the ISP 20 is 
connected to the Internet 30. 

The access server 22 in the ISP 20 includes a modem pool 
for linking its customers to the Internet 30. The ISP 20 has 50 
a need for a significant amount of administrative support in 
order to track and manage each subscriber's access to the 
Internet 30. A Remote Authentication Dial-In User Service 
(RADIUS) server 40 provides this administrative support to 
the ISP 20. The RADIUS server 40, in general, provides 55 
authentication, authorization, and accounting services for 
the ISP 20. A RADIUS server may also provide routing and 
tunneling support in some implementations, which will 
become more apparent from the description below. Whsa, 
th e ISP 20 begins a session for a subscribe r ( theJ§ ] g2fl,sends 60 
anauthent ication request message to the ^ RADjUS r serYeL40 
de|i5rnJing*tK 

pro^JfjSJTThis message typically also includes the subscrib- 
ePsname and the subscriber's password. Upon receipt of the 
authentication request message, the RADIUS server 40 65 
sends an acknowledgment that the message has been 
received with authentication results. The RADIUS server 40 
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verifies the subscriber's name passed from the access server 
22 and the password and also returns configuration infor- 
mation to the access server 22 for that particular subscriber. 
If authentication is successful, a start accounting message is 
sent to the RADIUS server 40. At the end of a session with 
a subscriber, the access server 22 sends a stop message 
indicating the type of service that was delivered and possibly 
other information, such as elapsed time. The services that 
may be provided to the subscriber include SUP, PPP, Telnet, 
or rlogin. Additional information on the RADIUS server 40 
may be found in Rigney et al., Remote Authentication 
Dial-In User Service (RADIUS), Network Working Group, 
January, 1997, or in Rigney et al, RADIUS Accounting, 
Network Working Group, April, 1997. 

One challenge facing the ISP 20 is striking a balance 
between efficient utilization of its resources and providing 
capacity to meet subscriber demand. Th e resources of th e 
I SP 20 is predominantly its pool of modemsLand tfteJSIL 20 
t ries to minim lze'itis cost fay .eDSjiangihat_all of its modem s 
o perate at peak capacity . To provide a quality service to its 
subscribers^ on the other hand, the ISP 20 should ideally be 
able to provide access to the Internet 30 for each subscriber 
whenever he or she wants and should strive to provide each 
customer with maximum bandwidth. The ISP 20 typically 
strikes this balance by attempting to closely shape its 
capacity to customer demand and by reducing transfer 
speeds when demand for services increases. Due to the 
difficulty in estimating customer demand and due to fluc- 
tuations in the demand and in the subscriber base, the ISP 20 
is often operating at peak capacity and is unable to accom- 
modate any more calls from its subscribers. 

This difficulty in reaching the ISP 20 can be problematic 
for both the ISP 20 as well as for the Local Exchange Carrier 
(LEC). For the ISP 20, the subscriber is likely frustrated that 
he or she cannot reach the ISP 20 and may decide to 
discontinue service with the ISP 20 and sign up with another 
ISP that can offer better quality service. Even when the 
subscriber is able to connect with its ISP 20, the subscriber 
is often frustrated by the limited amount of available band- 
width and to the resultant slow transfer speeds. For the LEC, 
a subscriber who cannot initially make contact with its ISP 
20 often repeatedly attempts to make contact with the ISP 20 
and may continue to do so until communications are estab- 
lished. Each time that the subscriber attempts to contact his 
or her ISP 20, the subscriber consumes valuable resources of 
the PSTN 10 since each call requires a considerable amount 
of processing and signaling within the PSTN 10, including 
signaling between an SSP and STP associated with the 
subscriber and between an SSP and STP associated with the 
ISP 20. Additional resources of the PSTN 10 may also be 
consumed if queries are sent to an SCP, such as when the 
subscriber dials a 1-800 number to reach the ISP 20. A need 
therefore exists for a way of more efficiently controlling and 
managing the resources of an ISP and of the PSTN. 
II. Network Overview 

A network 100 for more efficiently controlling and man- 
aging resources of an ISP and of the PSTN is shown in FIG. 
3. The network 100 includes subscribers having computers 
14 who are provided Internet access through one or more 
ISPs. Each computer 14 is connected to one of the central 
offices 16 within the PSTN. As shown in FIG. 2, a number 
of subscribers with computers 14 are connected to one of the 
central offices 16 within the PSTN 10. The central offices 16 
and the tandem switch 18 are connected to one or more 
access servers 22, preferably through Primary Rate ISDN 
lines (PRI). The central offices 16 are also connected to an 
SCP 42 which provides Local Number Portability (LNP) 
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services to the PSTN 10. The network 100 additionally 
includes an Intelligent Traffic Routing and Control 
(1NTRAC) unit 45 connected to the SCP 42 and a resource 
tracker 50 connected to the RADIUS server 40. Although the 
INTRAC unit 45 is illustrated as a separate item from the S 
SCP 42, as described in more detail below, the INTRAC unit 
45 preferably resides on the SCP 42 as a Service Package 
Application (SPA). 

As described above, on e applicationjiL aJlADMJS»server 
p rovides au^enti cjitfo sc r- 10 

vjc^JsUteJS&^°- This ^ application of a RADIUS 
server is typically associated with a single ISP 20 and is a 
Level 2 Tunneling Protocol (L2TP) Network Server, com- 
monly referred to as an LNS. A second application of a 
RADIUS server, such as RADIUS server 40' shown in FIG. is 
3, generally provides routing and tunneling support for an 
LEC. This application of RADIUS server 40' is an L2TP 
Access Concentrator, commonly referred to as a LAC. After 
receiving a call from a subscriber, an Access Server 22 
queries the RADIUS server 40" for level 2 tunneling infor- 20 
mation. In response to one of these queries, the RADIUS 
server 40' determines how to route the call through the 
LEC's Wide Area Network (WAN) 26 so that the call 
reaches the proper destination with the Internet 30. The 
WAN 26 may comprise any suitable type of network, such 25 
as a frame relay or Asynchronous Transfer Mode (ATM). 
Upon reaching an ISP within the Internet, such as AOL, the 
ISP has its LNS RADIUS server 40 for providing the 
authentication, authorization, and accounting services. 

The network 100 is not limited to the RADIUS server 40' 30 
but may encompass other types of servers and is preferably 
a DIAMETER server 40'. The DIAMETER protocol is an 
enhancement to the RADIUS protocol and is backward 
compatible with the RADIUS protocol. The RADIUS pro- 
tocol has a limited command and attribute address space and 35 
is not in itself an extensible protocol. The RADIUS protocol, 
furthermore, assumes that there are no unsolicited messages 
from a server to a client. The DIAMETER protocol, on the 
other hand, supports new services and permits a server to 
send unsolicited messages to clients on a network As a 40 
result, the RADIUS server 40', if implemented as a DIAM- 
ETER server 40', supports messages from it to any of the 
Access Servers 22. This allows the acquisition of additional 
state information applicable to the resource tracker. Various 
proprietary "DIAMETER"-like client/server approaches 45 
may also be used with the invention. 

While FIG. 3 depicts access servers 22, the ISP is not 
delineated in the figure for reasons that will become appar- 
ent from the following description. As explained in more 
detail below, the access servers 22A to 22C may be operated 50 
by a single ISP or by multiple ISPs. Furthermore, the ISPs 
may not operate the access servers 22 but instead may have 
a data connection to the PSTN 10, with the circuit to packet 
adaptation being performed through the access servers 22 by 
a different entity, such as by a Local Exchange Company 55 
(LEC). Thus, the data calls intended for an ISP may be 
packetised prior to being delivered to the ISP. A first ISP, for 
instance, may be connected to the output of access server 
22 A, a second ISP may be connected to the output of access 
server 22 B, and a third ISP may be connected to the output 60 
of access server 22C. A single ISP, of course, may be 
connected to more than one access server 22, whereby a 
single ISP may be connected to the outputs of all access 
servers 22A to 22C. 

The network 100 also includes a resource table 43 . As will 65 
be explained in more detail below, the resource table 43 may 
be connected to the INTRAC unit 45 or may instead be 
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connected to the resource tracker 50. Furthermore, although 
the resource table 43 has been shown as a separate element, 
the resource table 43 may be incorporated in and form a part 
of the INTRAC unit 45 or the resource tracker 50. The 
connections between the resource table 43 and both the 
INTRAC unit 45 and resource tracker 50 have therefore 
been shown in dashed lines since the resource table 43 is not 
limited to its illustrated location. 
III. INTRAC 

An operation according to one embodiment of the inven- 
tion of the network 100 will now be described with reference 
to FIG. 4. At a step 61, a subscriber initiates a call to its ISP 
through computer 14 and initiates a call to its ISP through 
one of the central offices 16. At step 62, the central office 16 
receives the called number from the subscriber and is 
triggered to send a query to an SCP. This query is passed 
through an STP 41 to the SCP 42. 

At step 63, the SCP 42 receives the query from the central 
office 16 through the STP 41 and determines whether the 
resource tracker 50 should be queried. According to one 
aspect of the invention, the INTRAC unit 45 does not query 
the resource tracker 50 but instead processing continues at 
step 64 with the INTRAC unit 45 retrieving routing direc- 
tions for the ISP directly from the resource table 43. These 
routing directions are returned in a response to the central 
office 16 at step 68. 

The INTRAC unit 45, based on the reply from the 
resource table 43, determines whether sufficient resources 
are available at step 66 and formulates an appropriate 
response to the SCP 42. This appropriate response contains 
routing directions for directing the call to a preferred loca- 
tion within the PSTN. If the response from the resource table 
43 indicates that sufficient resources are available, then the 
INTRAC unit 45 at step 68 returns a response to the central 
office 16 which contains the routing directions. On the other 
hand, if resources are not available, then the INTRAC unit 
45 at step 67 will return a response to the central office 16 
terminating the call, such as by providing a busy signal to the 
caller. 

In the preferred embodiment, the central office 16 per- 
forms an LNP trigger and sends an LNP query to the SCP 42. 
The routing directions returned in the response from the 
INTRAC unit 45 at step 68 preferably contains the Local 
Routing Number (LRN) for where the subscriber's call 
should be routed. Through use of the LNP trigger, LNP 
query, and LRNs, calls to an ISP and other data-related calls 
can be directed away from the PSTN 10 and onto dedicated 
trunks for data calls. As shown in FIG. 3, for instance, each 
SSP or central office 16 is directly connected to an access 
server 22 and the LRN directs the subscriber's call to a trunk 
group interconnecting the central office 16 to the access 
servers 22. 

The signaling between the SCP 42 and the STP 41 and 
central offices 16 is not altered with the invention. The 
signaling to and from the SCP 42 conforms to Signaling 
System 7 (SS7) and appears as a typical LNP inquiry and 
response. 

At step 64, the INTRAC unit 45 retrieves the routing 
directions in any suitable manner. The INTRAC unit 45 
preferably uses the resource table 43 which holds the LRNs 
for each ISP. When the INTRAC unit 45 receives a query 
from an SSP 16, the INTRAC unit 45 performs a look-up 
function in the resource table 43 to find the appropriate LRN 
for the called telephone number and returns the LRN in a 
response to the LNP query at step 68. 
IV Resource Tracker 

According to another aspect of the invention which 
involves the resource tracker 50, the INTRAC unit 45 
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formulates a resource query at step 65. The resource query, 
as will be described in more detail below, is a query sent 
from the INTRAC unit 45 lo the resource tracker 50 to 
inquire as to the resources available for the subscribers call. 
The resource tracker 50 receives the resource query and, in 
response, checks the available resources of the ISP. Based on 
its evaluation of ISP resources through its connection to the 
RADIUS server 40", the resource tracker 50 returns an 
appropriate response to the INTRAC unit 45 with informa- 
tion about the available resources at step 66. According to 
this embodiment, the resource table 43 is managed by the 
resource tracker 50. In response to receiving the resource 
query, the resource tracker 50 consults with the resource 
table 43 to find a preferred LRN for the subscriber's call. 

The signaling between the access servers 22 and the 
RADIUS server 40' is not changed with the invention. The 
access servers 22 communicate with the RADIUS server 40' 
according to the RADIUS accounting protocol, or other 
suitable protocols. The resource tracker 50 preferably com- 
municates with the INTRAC unit 45 according to GR1129- 
CORE, a signaling protocol defined in AIN 0.2, although 
other protocols may be used, such as 1129+, 1129A, TCP/IP, 
or another protocol. 

V. Call Routing 

Regardless of how the INTRAC unit 45 obtains the LRN, 
the LRN is provided to the switch to direct the call to a 
preferred location or trunk group. The LRN, for instance, 
may redirect the subscriber's call to a different location or, 
alternatively, simply contains the same telephone number 
called by the subscriber. The INTRAC unit 45 therefore may 
rely upon the resource tracker 50 to redirect calls, to 
determine whether resources are available to connect the 
subscribers call, or to determine whether the subscriber's 
call should be terminated. 

One advantage of the network 100 over the conventional 
network shown in FIG, 2 is that ISPs no longer need to have 
a concentrated Point of Presence (POP). Typically, as shown 
in FIG. 2, an ISP 20 is connected to the PSTN 10 through 
a single egress switch such as central office 16, through PRIs 
24. This concentrated POP for the ISP 20 renders it difficult 
and expensive to relocate the ISP 20 to another location, 
both for the ISP 20 and for the LEC. For the LEC, moving 
an ISP from one location to another location is tremendously 
expensive since the LEC must build the infrastructure nec- 
essary to support the ISP at the new location and the 
investment at the old location must be dismantled at a great 
loss to the LEC. 

The network 100 shown in FIG. 3, in contrast, does not 
require the ISP to have a concentrated POP. Rather than 
directing all calls to an ISP through a single central office 16, 
each SSP 16 in network 100 preferably has a direct connec- 
tion to the ISP through one of the access servers 22. The 
LRN returned to the SSP therefore directs the SSP to a 
specified trunk or trunk group in order to route the data call 
to the access servers 22. The connections between the SSPs 
and the access servers are preferably PRI lines. By directing 
calls from each ingress switch to the access servers 22 and 
away from the PSTN, costs associated with handling data 
calls are substantially reduced. For the ISP, the use of LRNs 
to route calls from their subscribers offers flexibility in how 
the ISPs network are built and distributed, both from a 
viewpoint of timing and geography. 

VI. Resource Query 

A process 70 for generating the resource query at step 65 
of FIG. 4 will now be described with reference to FIG. 5. 
The process 70 explains in more detail steps that occur after 
a determination has already been made by the INTRAC unit 
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45 that a query should be sent to the resource tracker 50. At 
a step 71, after the INTRAC unit 45 receives the query from 
the SSP, the INTRAC unit 45 sends a resource query to the 
resource tracker 50. The resource query includes the called 

s telephone number, thereby designating the ISP, and may also 
include the calling party's telephone number, thereby des- 
ignating the subscriber. At step 72, the INTRAC unit 45 
receives a response from the resource tracker 50 and 
determines, at step 73, whether to generate any additional 

10 resource queries. These additional resource queries, as dis- 
cussed in more detail below, may query the resource tracker 
50 as to the available resources of other access servers or 
other ISPs. The additional resource queries, moreover, may 
query the resource tracker 50 as to preferred resources that 

15 are available for a particular subscriber. If additional queries 
are made, then processing returns to step 71 where the 
resource query is formulated and to step 72 where the 
response is received from the resource tracker 50. 
When no more resource queries are needed, the INTRAC 

20 unit 45 at step 74 evaluates the resources available to the 
subscriber. This evaluation focuses, according to established 
criteria, on the most desired access server, the most desired 
ISP, or other factors that are influential in directing the 
subscriber's call. At step 75, the INTRAC unit 45 issues an 

25 appropriate reply to the central office 16. If resources are 
available for the subscriber, then the reply sent to the central 
office 16 includes the LRN for routing the subscriber's call. 

The evaluation of resources may alternatively be per- 
formed by the resource tracker 50 instead of by the INTRAC 

30 unit 45. The INTRAC unit 45 sends the resource query to the 
resource tracker 50 with this query containing the called 
telephone number and possibly also the calling party's 
telephone number. The resource tracker 50 selects the 
desired LRN for the subscriber's call based on decision-tree 

35 routing stored within the resource tracker 50. This decision - 
lime routing can be customized for an ISP, an LEC, or other 
entity. The resource tracker 50 checks the telephone number 
called by the subscriber and return a response indicating 
whether resources are available at that number. The resource 

40 tracker 50 may perform additional processing and find an 
optimal LRN for the subscriber based on the called tele- 
phone number and possibly also based on the calling party's 
telephone number. An advantage of having the evaluation of 
resources performed at the resource tracker 50 is that the 

45 resource queries and the responses to these queries can be 
eliminated. 

VII. Tracking Resources 

A method 80 for tracking the resources of an access server 
or ISP at the resource tracker 50 will now be described with 

50 reference to FIG. 6. At a step 81, the resource tracker 50 sets 
the maximum value of a counter to the peak capacity of the 
access server or ISP, or other desired maximum. As an 
example, if the ISP has 100 modems available, the resource 
tracker 50 sets the counter to a value of 100. At step 82, the 

55 resource tracker 50 determines whether a change in a session 
has occurred. The RADIUS server 40', as discussed above, 
receives start and stop messages from the access servers and 
ISPs when sessions begin and when they terminate, respec- 
tively. The resource tracker 50 monitors these start and stop 

60 messages and determines that a change in a session occurs 
when either of these messages is received. At step 83, the 
resource tracker 50 determines whether a session has started 
and, if so, decrements the counter at step 84. At step 85, the 
resource tracker 50 determines whether a session has 

65 stopped and, if so, increments the counter at step 86. The 
process 80 returns to step 82 to detect the next change in a 
session. The available resources of each ISP are stored in the 
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resource table 43. This functionality remains the same 
whether the ISP's resources are provided by a single Access 
Server or multiple Access Servers dispersed across a wide 
geographical area. 

In general, through the method 80 and counters, the 
resource tracker 50 tracks the number of available resources 
and reduces the value in the counter for each new session 
that has started. Conversely, when a session terminates, the 
resource tracker 50 increments the counter to reflect new 
resources that have become available to the network 100. 
According to one aspect of the invention, the resource 
tracker 50 has a counter for each ISP that it is monitoring and 
each counter reflects the total number of resources available 
for that ISP. According to a further aspect of the invention, 
the resource tracker 50 has a plurality of counters for each 
ISP with each counter reflecting the available resources 
within part of the ISR Each counter, for instance, may be 
dedicated to a single Point Of Presence (POP) managed by 
the ISP with a single ISP having plural POPs. As another 
example, each counter may be dedicated to a single access 
server within an ISP. One access server, for instance, may 
provide K56 service and a second access server may provide 
K56Hex service to its subscribers while yet another may 
offer more recently developed modem techniques, such as 
V.90. Other uses and examples of the counters for tracking 
and monitoring resources of an ISP will become apparent to 
those skilled in the art. 

The resources of the ISP can alternatively be monitored 
through the SCP 42 and INTRAC unit 45. Through moni- 
toring of call set-up signaling and termination notification 
signaling to the ISP, the INTRAC unit 45 determines the 
resources available at the ISP. The INTRAC unit 45, based 
on this determination, then updates the resource table 43 to 
reflect the available resources. 
VIII. Data Signaling 

A preferred method of directing a subscriber's call to the 
INTRAC unit 45 will now be described. When the subscrib- 
er's call is received at the SSP 16, the SSP 16 determines that 
the call is to a local number and is triggered to perform an 
LNP query. In general, queries passed from an SSP to an 
SCP and responses from the SCP to the SSP pass through a 
Common Channel Signaling System (CCS7) network that 
includes the STPs. A CCS7 message is comprised of three 
parts: an MTP part that contains the Routing Label, an SCCP 
part that contains the Global Title (GT), and a data field. The 
data for a call setup is defined as ISDN User Part (ISUP) data 
and data for database services is defined as Transaction 
Capability Application Part (TCAP) data. 

An explanation will first be given for the signaling that 
occurs when a subscriber calls a ported telephone number 
which requires LNP call processing. The SSP 16 receiving 
the call inserts its point code in Originating Point Code 
(OPC) 96 and inserts the capability of a local STP41 pair in 
the Destination Point Code (DPQ 97, with the OPC 96 and 
DPC 97 together forming the Routing Label for the query 
90. The Called Party Address 94 of the query 90 includes a 
Global Title (GT) which the SSP 16 populates with the 
ten-digit dialed telephone number and also includes a Sub- 
System Number (SSN) which the SSP 16 populates with all 
zeros. In a Calling Party Address 93 part of the SCCP 92, the 
SSP 16 inserts the point code for the SSP 16 and the AIN 0.1 
Sub-System Number for the SSP 16. The TCAP 91 part of 
the query 90 includes a Transaction ID (TID) identifying the 
call, a Trigger Type (IT) identifying the type of trigger 
detected by the SSP 16, and a Service Key (SIC) equal to the 
ten-digit dialed number. The STP 41 receives this query 90 
and performs a Global Tide Translation (GIT) and changes 
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the Routing Label 95 before sending the query 90 to the SCP 
42 that performs LNP call processing. 

An explanation of call signaling according to a preferred 
embodiment of the invention will now be provided. When a 
subscriber call its ISP or otherwise makes a data call, the 
SSP 16 receiving the call performs an LNP query 90 when 
the call is to a local number. The LNP query 90, according 
to standard LNP call processing, is passed to the STP 41 for 
Global Title Translation and the STP 41 launches a refor- 
matted query 90 to the SCP 42 for processing. 

In contrast to a conventional LNP query 90, though, the 
LNP query 90 according to the invention is rerouted when 
the call is a data call. A diagram of the SCP 42 and a method 
100 according to a preferred embodiment of processing the 
query 90 at the SCP 42 will now be described with reference 
to FIGS. 8 and 9, respectively. The SCP 42 includes a 
Service Package Manager 102 for receiving queries from the 
STP 41 through the CCS7 network, a database 103, the 
INTRAC unit 45, and an LNP processing unit 104. In the 
preferred embodiment, the INTRAC unit 45 and the LNP 
processing unit 104 are each a Service Package Application 
(SPA) within the SCP 42 and share the same SSN and 
translations type. At a step 111, the Service Package Man- 
ager 102 within the SCP 42 receives the query 90 from the 
STP 41 through the CCS7 network. The Service Package 
Manager 102 at step 112 compares the dialed telephone 
number in the Called Party Address 93 field of the query 90 
to numbers stored in database 103 to determine whether the 
call is a data call, such as to an ISP. The telephone numbers 
identifying data calls are preferably collected at a central 
location and downloaded to the various SCPs 42 through a 
Service Management System 107. 

If the dialed telephone number does not identify the call 
as a data call by the primary Routing Key, then at step 113 
the Service Package Manager 102 generates a default Rout- 
ing Key and passes the call for LNP call processing. A 
Routing Key is comprised of an SSN, a Trigger Type, and a 
Service Key. The SSN in the Routing Key typically is 
populated by an SCP with the SSN in the SCCP Called Party 
Address, and the Trigger Type and Service Key are both 
acquired from the TCAP part of the query 90. At step 113, 
the Routing Key is generated in the conventional manner 
and at step 114 standard LNP call processing is performed 
by the LNP processing unit 104. The LNP processing unit 
104 performs a look-up function in a database 105 and 
inserts the LRN of an SSP 16 serving the called party in the 
Called Party Address 94 and inserts the actual called-party 
telephone number is placed in a Generic Address Parameter 
(GAP) field. For an LNP query that does not involve a data 
call, the LNP call processing is not effected by the INTRAC 
unit 45 and signaling within the PSTN occurs in the standard 
way. 

In contrast, when the Service Package Manager 102 finds 
a match between the dialed telephone number and an entry 
in the database 103 at step 1 12, then the Service Package 
Manager 102 generates a Routing Key at step 115 specific 
for the INTRAC unit 45. This Routing Key contains the 
same Trigger Type and Service Key as those in the Routing 
Key generated at step 113 for a call that should be routed to 
the LNP processing unit 104. The SSN populated by the 
Service Package Manager 102 at step 115 is a SSN unique 
to the INTRAC unit 45. Based on the Routing Key, the SCP 
42 passes the query 90 to the INTRAC unit 45 at step 116 
for further processing. The INTRAC unit 45, as with the 
LNP processing unit 104, inserts a preferred LRN in the 
Called Party Address 94, with this LRN being obtained 
directly from the resource table 43, either through a look-up 
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function or through the resource tracker 50. Although the 
resource table 43 has been shown separately from the SCP 
42, it should be understood from the description above that 
the resource table 43 would preferably be a real-time data- 
base on the SCP 42. The resource table 43, for instance, may 
form a part of the database 105. 
IX. Resource Table 

A preferred example of the resource table 43 is shown in 
FIG. 10. The resource table 43 includes a customer identi- 
fication number uniquely identifying a particular ISP. 
Although only two customer IDs have been shown in FIG. 
10, the resource table 43 typically contains a greater number 
of customer IDs. For each customer ID, the resource table 43 
includes a number of telephone numbers assigned to that ISP 
with these telephone numbers being represented by tele- 
phone numbers 1, 2, ... N. The resource table 43 further 
includes an entry for the volume of calls permitted to that 
ISP, such as 50 calls, and the present number of active calls. 
The resource table 43 may also include an entry enabling the 
routing of overflow calls and also one or more entries 
designating the LRNs for overflow calls. 

With resource table 43, the resource tracker 50 or 
INTRAC unit 45 can easily derive appropriate routing 
directions for a subscriber's call. By checking the peak 



a preferred LRN and can also terminate the call if resources 
are not available. 

According to another aspect of the invention, the network 
100 includes both the INTRAC unit 45 and the resource 
s tracker 50. The resource tracker 50 determines whether the 
call initiated by the subscriber through computer 14 should 
be routed to the ISP or should be intercepted based on the 
available resources. The resource tracker 50 determines 
whether the ISP has resources available for the subscriber 
and generates an appropriate reply to the INTRAC unit 45 
at step 66. If resources are available, the call is completed in 
its usual manner through the PSTN 10 to the access server 
22. If, on the other hand, resources are not available at the 
ISP, then the subscriber's call is intercepted before further 
signaling occurs within the PST>J 10 and the subscriber 
15 receives a busy signal at step 67. The network 100 according 
to this aspect of the invention connects the subscriber to the 
ISP or intercepts the call and is able to reduce signaling 
within the PSTN. 
According to a further aspect of the invention, the net- 
20 work 100 includes both the resource tracker 50 and 
INTRAC unit 45 and the resource tracker 50 returns a LRN 
to the INTRAC unit 45. As discussed above, the LRN 
returned by the resource tracker 50 is chosen from the 
resource table 43 based on any suitable criteria. In one 



volume of the ISP and the number of active calls, the 25 example, the resource tracker 50 selects the LRN based on 

resource tracker 50 or INTRAC unit 45 can determine a preferred access server 22. With reference to FIG. 3, the 

whether calls can be routed to that ISP. If the ISP is at peak access server 22 comprises a plurality of access servers 22 A, 

capacity, then the resource tracker 50 or INTRAC unit 45 22B, and 22C. When a subscriber calls in to any one of these 

checks whether overflow capacity is enabled and, if so, access servers 22A, 22B, or 22C, an LNP query is initiated 

where the call should be routed. The customer identification 30 at the central office 16 and a resource query is generated by 



and overflow routing can be contained within a single ISP or 
may encompass a multitude of ISPs. A single ISP, for 
instance, may have a plurality of "customer" identification 
numbers with each customer ID relating to a separate class 
of service. In this manner, the resource tracker 50 or 
INTRAC unit 45 performs processing based on the desired 
class of service for a subscriber. The overflow according to 
this arrangement directs calls to a less desired type of service 
within the ISP or to other ISPs offering that service. The 



the INTRAC unit 45. The resource tracker 50, according to 
this example, tracks the resources available for each of the 
access servers 22A, 22B, and 22C through one or more 
counters. The resource tracker 50 includes the LRN in its 
35 response to the INTRAC unit 45 so that the subscriber is 
directed to an access server 22 that has excess capacity. For 
instance, if the access server 22 called by the subscriber is 
at peak capacity or is presently consuming more than a 
certain threshold of capacity, the resource tracker 50 and 



customer IDs may instead be dedicated to different POPs of 40 INTRAC unit 45 direct the subscriber's call to the access 

an ISP with subscribers preferably being directed to the server 22 having excess capacity. As an example, an initial 

closest POP and with overflow calls being directed to other call from computer 14 to access server 22A is redirected to 

POPs of the ISP. Instead of directing calls to another POP or access server 22C when access server 22 A is at peak 

type of service within a single ISP, the overflow may direct capacity and access server 22C has excess capacity. After the 

calls to a secondary or back-up ISP. As will be appreciated 45 access server 22 with excess capacity has been located, the 

by those skilled in the art, the resource table 43 can be INTRAC unit 45 inserts the LRN to direct the subscribers 

configured in various other ways and should not be limited call to this access server 22 and returns the response to the 

to the example shown in FIG. 10. central office 16 through the STP 41. To the central office 16 

X. Network Configurations and the PSTN 10, the telephone number called by the 

Based on the descriptions above, the network 100 can be 50 subscriber appears to have been a ported number and the 



configured in a multitude of ways, depending upon the 
specific application. According to one aspect of the 
invention, the network 100 does not include the resource 
tracker 50 and the INTRAC unit 45 does not perform any 
resource query. Instead, the INTRAC unit 45 receives que- 
ries from the subscriber's SSP, derives a desired LRN from 
the resource table 43, and inserts the desired LRN in a 
response returned to the SSP. The INTRAC unit 45 may 
simply look up the LRN in the resource table 43 or may 



PSTN 10 provides the appropriate LRN for the subscriber's 
call. 

The criteria used in selecting the preferred LRN is not 
limited to a particular access server within a single ISP, but 
ss rather may be used to allocate resources between two or 
more ISPs. For instance, when resources for a first ISP are 
at peak capacity or above a certain threshold level of 
capacity, the INTRAC unit 45 redirects calls away from that 



first ISP to a second ISP having excess capacity. The 
perform some processing of information in the resource 60 resource queries sent from the INTRAC unit 45 are therefore 
table 43 before arriving at the desired LRN. concerned not only about the capacity within the first ISP but 

According to another embodiment of the invention, the can also look to the resources of other ISPs. Thus, for 
INTRAC unit 45 and SCP 42 may monitor the resources of instance, if MindSpring is at peak capacity, the INTRAC 
the ISPs. As discussed above, the INTRAC unit 45 tracks the unit 45 and resource tracker 50 can redirect MindSpring 
resources available in an ISP by monitoring call set-up 65 subscribers to a secondary ISP, such as BellSouth.net. 
signaling and termination notification signaling. The Instead of, or in addition to, the criteria of access server 
INTRAC unit 45 can therefore direct the subscriber's call to and ISP, the LRN may be selected based on particular 
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information concerning the subscriber. According to this as well as the ISP, the resource tracker 50 may track the total 

example, the resource tracker 50 and INTRAC unit 45 direct amount of time that calls were connected to an ISP. The 

a subscriber to a preferred resource for that particular resource tracker 50 can track the time in a multitude of ways, 

subscriber. The RADIUS server 40', as discussed above, As one example, the resource tracker 50 effectively has a 

contains configuration information on each subscriber to an 5 timer associated with each call that is directed toward an ISP 

ISP, including information on the type of service that the and starts the timer in conjunction with decrementing the 

subscriber is configured for with the ISP. The INTRAC unit counter at step 84 and stops the timer in conjunction with 

45 and resource tracker 50 can thus find an access server or incrementing the counter at step 86. The times associated 

ISP that offers the preferred service or resource for that with connections to an ISP can be stored in the resource table 

subscriber. As an example, for a subscriber having an X2 10 43. Alternatively, rather than monitor actual time, the 

modem, the LRN selected by the INTRAC unit 45 and resource tracker 50, INTRAC unit 45, or access servers 22 

resource tracker 50 directs the subscriber's call to a resource may monitor the actual payload delivered to the ISP. 

that provide X2 service, rather than the K56Flex service. Furthermore, rather than the resource tracker 50 monitoring 

The INTRAC unit 45 and resource tracker 50 preferably first the time, the INTRAC unit 45 may monitor the times 

check the resources of the access server 22 called by the 15 associated with an ISP and store the times in the resource 

subscriber, followed by other access servers 22 managed by table 43. 

the subscriber's ISP, and then to other ISPs, if enabled, that The forgoing description of the preferred embodiments of 

can offer service for that subscriber. The configuration the invention has been presented only for the purpose of 

information used by the INTRAC unit 45 and resource illustration and description and is not intended to be exhaus- 

tracker 50 in directing the subscriber's call is not limited to 20 tive or to limit the invention to the precise forms disclosed, 

modem type but may encompass other types of information, Many modifications and variations are possible in light of 

such as the type of service delivered to the subscriber. Also, the above teaching. 

additional information may be stored in the RADIUS server For example, the INTRAC unit 45 preferably resides on 

40' and used by resource tracker 50 in directing calls within the SCP 42 and the resource tracker 50 resides on the 

the PSTN. 25 RADIUS server 40'. The INTRAC unit 45 and resource 

The evaluation of the best LRN for a subscriber can be tracker 50, however, may comprise separate components 

performed by the resource tracker 50, the INTRAC unit 45, distinct from the RADIUS server 40' and SCP 42. 

or both the resource tracker 50 and INTRAC unit 45. The As discussed above with reference to FIG. 4, when 

invention is not limited to having the selection being per- resources are not available to handle a subscriber's call, the 

formed only by the INTRAC unit 45 but instead encom- 30 call is terminated. The invention is not limited in the manner 

passes the selection being performed by the resource tracker in which the call is terminated. The call, for instance, may 

50 or the selection being shared by the resource tracker 50 be terminated by providing the calling party with a busy 

and INTRAC unit 45. signal. One possible way of providing this busy signal is 

According to a further aspect of the invention, the directing the subscriber's call to a "dummy" port on the 

resource tracker 50 automatically sends updates to the 35 switch which has no trunk group. As another example, the 

INTRAC unit 45 upon a change in resources for an ISP or calling party may be played an announcement with this 

at a predetermined period of time or set time. In the announcement informing the caller that the ISP or other 

examples discussed above, the INTRAC unit 45 only entity that the caller is trying to reach is not able to accept 

receives a response from the resource tracker 50 after the the call. 

INTRAC unit 45 sends a resource ISP query. The resource 40 The invention has been described primarily with reference 

tracker 50 may instead update the resource table 43 when- to a subscriber's call directed to an ISP. The invention, 

ever a subscriber begins or ends a session. The resource table however, is not limited to calls directed to just an ISP but 

43 for tracking the resources available for an access server encompasses any data call. The invention, for instance, may 

or ISP can therefore be connected to the INTRAC unit 45, be used to control and manage calls to a data network other 

whereby the INTRAC unit 45 would not query the RADIUS 45 than the Internet, such as a company's internal computer 

server 40' and resource tracker 50 to determine available network. 

network resources. The INTRAC unit 45, as discussed above, is preferably 

Data calls, as discussed above, pose a problem to the co-resident with the LNP processing unit 104 on the same 

PSTN in that they have long call durations (LCDs) and SCP 42. By placing the INTRAC unit 45 with the LNP 

consume valuable resources of the PSTN. The LECs expe- 50 processing unit 104, the LEC can reduce its cost and avoid 

rience another problem related to the routing of data calls. the need to deploy a set of SCPs dedicated for routing data 

The ISPs contend that they are another carrier and are calls separate from the set of SCPs that provide LNP call 

entitled to an access charge for receiving the call from the processing. The invention is not limited to any particular 

LEC. Although the validity of this argument is in doubt, the SCP. For an SCP that has both the LNP processing unit 104 

LECs have been placing money into a special account for 55 and the INTRAC unit 45, the SCP 42 is preferably a Lucent 

each call connected to an ISP. A problem to the LEC is that SCP having a Release 6.9 or higher, such as the Starserver 

the calls to the ISP are always one-way whereby the LECs FT Model 3300, although any SCP that allows for the use of 

cannot charge the ISPs for calls that terminate in the LECs Routing Keys with different Sub-System Numbers may be 

network from the ISP. used. 

The network 100 allows the LEC to redirect data calls off 60 The invention, moreover, is not limited to the PSTN but 

of the PSTN to an alternate interconnection arrangement. may be employed in other networks, such as a Private 

Through the arrangement shown in FIG. 3, LECs are now Branch Exchange (PBX). In a PBX, for instance, the 

able to not only monitor and better manage calls to the ISPs, INTRAC unit can intelligently route traffic to a certain 

but can also meter the length of data calls to an ISP as well destinations. The calls that are processed by the INTRAC 

as other data calls. Since each start and stop message sent to 65 unit therefore are not limited to just data calls but instead the 

the RADIUS server 40' is monitored by the resource tracker INTRAC unit may be used in the intelligent routing of voice 

50 and since each start or stop message identifies the caller or other types of calls. 
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The embodiments were chosen and described in order to 
explain the principles of the invention and their practical 
application so as to enable others skilled in the art to utilize 
the invention and various embodiments and with various 
modifications as arc suited to the particular use contem- 5 
plated. 

What is claimed is: 

1. A server for use in routing calls within a network, 
comprising: 

a call managing unit for receiving a query from a switch, 1Q 
the query being an LNP query generated for every call 
received at the switch; 

the call managing unit for determining whether the LNP 
query should have a firsi type of call processing or a 
second type of call processing; 15 

the call managing unit determining that the LNP query 
should have the second type of call processing if the 
call is a data call and should have the first type of call 
processing if the call is a non-data call; 

the call managing unit for accordingly directing the LNP 20 
query to a first processing unit for the first type of call 
processing or to a second processing unit for the second 
type of call processing; 

the first processing unit for performing the first type of 
call processing by deriving routing instructions for all 25 
non-data calls and for returning the routing instructions 
to the switch for the non-data calls, the first type of call 
processing comprising local aumber portability call 
processing; 

the second processing unit for performing the second type 30 
of call processing by deriving routing directions for all 
data calls and for returning the routing directions to the 
switch for the data calls, the second type of call 
processing for directing the data calls to a data network. 

2. The server as set forth in claim 1, wherein the network 35 
is a telephony network. 

3. The server as set forth in claim 1, wherein the second 
processing unit is for directing the data calls to an Internet 
service provider. 

4. The server as set forth in claim 1, wherein the second 40 
processing unit returns the routing directions for directing 
the data calls to a dialed telephone number different than a 
previous telephone number associated with the call. 

5. The server as set forth in claim 1, wherein the call 
managing unit determines whether the query should have the 45 
first or second type of call processing through a dialed 
telephone number in the call. 

6. The server as set forth in claim 5, wherein the call 
managing unit compares the dialed telephone number in the 
call to at least one stored telephone number. 50 

7. The server as set forth in claim 1, further comprising the 
first processing unit. 

8. The server as set forth in claim 7, wherein the first 
processing unit comprises a local number portability call 
processing unit for providing routing directions to the switch 55 
in response to the LNP query. 

9. The server as set forth in claim 1, wherein the call 
managing unit by default directs the query to the first 
processing unit for the first type of call processing. 

10. The server as set forth in claim 1, wherein the call 60 
managing unit directs the query to the first processing unit 

or the second processing unit depending upon a routing key 
associated with the query. 

11. The server as set forth in claim 1, wherein the server 
comprises a service control point and the second processing 65 
unit comprises a service package application resident on the 
service control point. 
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12. The server as set forth in claim 1, wherein the second 
processing unit derives the routing directions from a data- 
base. 

13. The server as set forth in claim 1, wherein the second 
processing unit derives the routing directions based on 
available resources. 

14. The server as set forth in claim 1, further comprising 
a database of telephone numbers and the call managing unit 
directs the query to the second processing unit if a dialed 
telephone number associated with the call is stored in the 
database. 

15. The server as set forth in claim 1, wherein the second 
processing unit returns routing directions to the switch for 
directing the call to a specified trunk. 

16. The server as set forth in claim 1, wherein the 
specified trunk comprises a data line interconnecting the 
switch to an access server. 

17. A telephony network, comprising: 

a switch for receiving a call and for being triggered to 
generate a query based on a destination telephone 
number associated with the call, the query being an 
LNP query generated for every call received at the 
switch; 

a service control point for receiving the LNP query from 
the switch; 

the service control point for determining whether the LNP 
query should have a fist type of call processing or a 
second type of call processing based on the destination 
telephone number, 

the service control point determining that the LNP query 
should have the second type of call processing if the 
call is a data call and should have the first type of call 
processing if the call is a non-data call; 

the service control point for accordingly directing the 
LNP query to a first processing unit for the first type of 
call processing or to a second processing unit for the 
second type of call processing; and 

the first processing unit for performing the first type of 
call processing by deriving routing instructions for all 
non-data calls and for returning the routing instructions 
to the switch for the non-data calls, the first type of call 
processing comprising local number portability call 
processing; 

the second processing unit for performing the second type 
of call processing by deriving routing directions for all 
data calls and for returning the routing directions to the 
switch for the data calls, the second type of call 
processing for directing data calls to a data network; 

wherein the switch routes the call based on the routing 
directions received from the second processing unit. 

18. The telephony network as set forth in claim 17, 
wherein the switch generates the query in response to a local 
number portability trigger. 

19. The telephony network as set forth in claim 17, 
wherein the service control point determines whether the 
query should be sent to the second processing unit based on 
a routing key associated with the query. 

20. The telephony network as set forth in claim 17, 
wherein the second processing units is resident on the 
service control point. 

21. The telephony network as set forth in claim 17, 
wherein the first and second processing units comprise 
service package applications resident on the service control 
point. 

22. The telephony network as set forth in claim 17, 
wherein the service control point determines whether the 
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query should be sent to the second processing unit based on 32. The method as set forth in claim 28, further compris- 

a telephone number in the query. ing receiving the call at the switch and generating the query 

23. The telephony network as set forth in claim 22, in response to a trigger. 

wherein the telephone number is a called party's telephone 33. The method as set forth in claim 28, wherein deter- 

number. S mining includes determining whether a condition is satisfied 

24. The telephony network as set forth in claim 22, anc j wherein the query is determined to require the first type 
wherein the telephone number is a calling party's telephone of call processing by default and the query is determined to 
number require the second type of call processing only if the 

25. n,e telephony network as set forth in claim 22, condition * satisfied. 

wherein the service control point determines whether the 10 ^ ^ mM ^ ^ fonh [n ^ 33 wherein delef _ 

query should be sent to the second processing unit by . tU t , .... .* c j 

^. *u»iu , j . u r » i mining whether the condition is satisfied comprises com- 

companng the telephone number to a database of stored - » L . ^ . , , 

telephone numbers paring a telephone number associated with the query to at 

26. The telephony network as set forth in claim 25, further Ieasl one Predetermined telephone number, 
comprising a service management system for receiving the 15 35 " ^ mcthod as sct forth lD claim 34 ' whcrcin lhc 
telephone numbers to be placed in the database and for telephone number associated with the query comprises a 
transferring the telephone numbers to the service control callin S party's telephone number. 

point for placement within the database. 36. The method as set forth in claim 34, wherein the 

27. The telephony network as set forth in claim 17, telephone number associated with the query comprises a 
wherein the second processing unit derives the routing 20 called party's telephone number. 

directions based on resources available to receive the call. 37. The method as set forth in claim 28, wherein deter- 

28. A method for routing calls within a network, com- mining comprises determining that the query should have 
prising: the second type of call processing when a routing key 

receiving a query from a switch, the query being an LNP associated with the query is equal to a predefined value, 

query; 25 38. The method as set forth in claim 28, wherein the first 

determining whether the LNP query should have a first and second processing units comprise first and second 

type of call processing or a second type of call pro- service package applications, respectively, on a service 

cessing; control point and directing comprises directing the query to 

determining that the LNP query should have the second citner the firsl or second service package application, 

type of call processing if the call is a data call; 39. The method as set forth in claim 28, further compris- 

determining that the LNP query should have the first type m S performing the first type of call processing, 

of call processing if the call is a non-data call; The method as set forth in claim 28, wherein deriving 

directing the LNP query to a first processing unit for the [ ouii ^ direcUons comprises deriving routing directions 

first type of call processing or to a second processing 35 based on available resources 

unit for the second type of call processing; 41 ^ mcthod as ^ forth ! n claim 28 ' whcrcm den ™S 

. „ - „ , . . routing directions comprises directing the call to a specified 

performing the first typo of call processing by deriving lfunk at thc switch 

routing instructions for all non-data calls the first type 42 ^ method as ^ forth ^ ^ 2g whefein ^ 

of call processing comprising local number portability ^ rouUog direclions uprises directing the call to a trunk for 

ca processing, carrying the call from the switch to an access server. 

performing the second type of call processing by deriving 43. method as set forth in claim 28, wherein deter- 

routing directions for all data calls, the second type of mining occurs within a service control point, 

call processing for directing data calls to a data net- 44 method as set forth in claim 28, further compris- 

work; and ^ mg receiving the routing directions at the switch and routing 

retiirning the routing directions to the switch. the call based on the routing directions. 

29. The method as set forth in claim 28, wherein receiving 45. The method as set forth in claim 28, wherein deter- 
the query is in response to receiving a data call at the switch. mining comprises comparing a telephone number associated 

30. The method as set forth in claim 28, wherein deter- with the query to a list of stored telephone numbers and 
mining whether the call should have the second type of call $Q further comprising receiving the list of stored telephone 
processing comprises comparing a telephone number asso- number from another location. 

ciated with the call to telephone numbers stored in a data- 46. The method as set forth in claim 45, wherein the 

base. location comprises a service management system and further 

31. The method as set forth in claim 28, wherein deter- comprising storing the list of telephone numbers at the 
mining whether the call should have the second type of call 5S service management system. 

processing comprises determining whether the call is 

directed toward an Internet service provider. * * * * * 
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